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ABSTRACT:  The  implementation  of  recommendations  from  the  Live-Virtual-Constructive  Architecture  Roadmap 
(LVCAR),  which  was  performed  under  the  auspices  of  the  U.S.  Office  of  the  Secretary  of  Defense  (OSD),  was  begun  in 
mid-2009.  Under  the  leadership  of  the  Joint  Training  Integration  and  Evaluation  Center  (JTIEC),  the  Johns  Hopkins 
University  Applied  Physics  Laboratory’  (JHU/APL)  has  undertaken  multiple  implementation  efforts  in  the  areas  of 
common  capabilities  for  LVC  simulations,  gateways  for  multi-architecture  LVC  simulations,  and  convergence  of  LVC 
simulation  architectures.  A  number  of  papers  presented  at  Simulation  Interoperability’  Workshops  since  the  spring  of 
2010  have  described  individual  activities  that  are  part  of  this  overall  effort. 

This  paper  provides  a  comprehensive  summary’  of  the  results  of  the  first  two  years  of  LVCAR  Implementation  (LVCAR- 
I)  efforts.  It  describes  accomplishments  in  the  development  of  new  prototype  standards  for  the  multi-architecture 
simulation  systems  engineering  process  and  for  multi-architecture  simulation  federation  agreements,  as  well  as  a  tool 
to  aid  in  the  implementation  of  such  federation  agreements.  It  also  discusses  candidate  business  models  to  enhance  the 
potential  for  reuse  of  LVC  simulation  tools,  and  pilot  efforts  to  explore  the  feasibility  of  such  business  models. 
Mechanisms  for  describing  L  VC  simulation  assets  using  standardized  metadata  are  described,  in  conjunction  with  the 
development  of  a  prototype  implementation  of  a  portal  for  discovering  and  locating  such  assets  for  subsequent 
download  for  reuse.  Additionally,  storage  formats  for  LVC  simulation-related  data  are  categorized,  along  with 
opportunities  for  improved  commonality.  Advances  in  the  description  and  characterization  of  simulation  gateways  are 
also  provided  that  will  permit  more  informed  selection  of  gateways  by  users  for  particular  applications. 

With  respect  to  current  and  future  trends  in  M&S  technology’,  the  paper  describes  efforts  related  to  Service-Oriented 
Architectures  (SOAs)  and  identifying  future  technologies  having  potential  use  for  the  DoD  Modeling  and  Simulation 
Community.  Finally,  the  paper  provides  an  overview  of  the  way  ahead  for  the  next  two  years  of  the  LVCAR 
implementation  effort. 


1.  Background 

The  Live-Virtual-Constructive  Architecture  Roadmap 
Implementation  (LVCAR-I)  and  Net-centric  Environment 
project  is  the  follow-on  effort  that  stems  from  findings  of 
the  LVCAR  Final  Report  [1],  The  purpose  of  the 
LVCAR  study  was  to:  “Develop  a  future  vision  and 


supporting  strategy  for  achieving  significant 
interoperability  improvements  in  LVC  simulation 
environments.”  The  focus  of  the  study  revolved  around 
four  dimensions  of  simulation  interoperability:  Technical 
Architecture,  Business  Models,  Standards  Evolution,  and 
Management  Processes.  The  precepts  that  guide  the 
study’s  implementation  are:  do  no  harm,  interoperability 
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is  not  free,  start  with  small  steps,  and  provide  central 
management.  Among  the  significant  results  of  the 
LVCAR  study  is  a  set  of  19  recommendations.  These 
recommendations  act  as  the  requirements  document 
found  in  formal  programs  and  is  used  to  guide  the 
LVCAR-I  tasks. 

The  principal  aims  of  LVCAR-1  are  to  explore 
organizational  and  structural  (e.g.,  use  of  standards) 
options  to  better: 

1 .  manage  LVC  architecture  interoperability; 

2.  create  reference  models  to  focus  data  and  service 
reuse  efforts; 

3.  reduce  LVC  architecture  divergence  and  tool 
proliferation;  and 

4.  explore  emerging  technology  issues  related  to  future 
LVC  architecture  performance  and  requirements. 

The  planning,  development,  and  execution  of  LVC  events 
are  universally  recognized  to  require  an  investment  of 
resources.  Also,  the  M&S  community  has  limited  agility 
with  regards  to  supporting  unforeseen  events.  Given  this 
situation,  the  objective  of  LVCAR-I  is  to  reduce 
overhead  and  provide  for  an  interoperable  M&S 
environment,  thus  improving  the  ability  to  construct  and 
conduct  timely  LVC  events.  Described  another  way,  the 
goal  for  LVCAR-I  is  to  get  M&S  support  inside  the 
military  operations  decision  cycle. 

The  project  leads  have  taken  a  holistic  approach  to 
organization  and  definition  of  an  acquisition  strategy. 
Fundamentally,  LVCAR-I  is  designed  to  work  in  an 
environment  where  there  are  many  different  factors  and 
incentives  that  influence  decisions,  including  willingness 
to  change  and  the  adoption  of  technical  solutions. 
Understanding  these  factors  and  their  effects  are  as 
important  to  the  success  of  the  project  as  the  technology 
advances  themselves.  As  a  result,  the  LVCAR-I  team 
distilled  the  19  recommendations  found  in  the  LVCAR 
study  to  the  grouping  of  core,  affiliated,  and  supporting 
efforts  as  described  in  Table  1. 

2.  Overview  of  the  LVCAR  Implementation 
Effort 

In  addition  to  the  19  LVCAR  recommendations  being 
grouped  as  shown  in  Table  1,  the  technical  efforts  being 
performed  as  part  of  LVCAR-I  were  subdivided  into  four 
major  technical  areas: 

1.  LVC  Common  Capabilities; 

2.  LVC  Gateways  and  Bridges; 

3.  LVC  Architecture  Convergence;  and 

4.  LVC  Future-Oriented  Efforts. 

Within  the  LVC  Common  Capabilities  technical  area, 
efforts  were  further  subdivided  into: 


a.  Systems  Engineering  Process 

b.  Federation  Agreements 

c.  Reusable  Tools  and  Common  Data  Storage  Formats 

d.  Asset  Reuse  Mechanisms. 
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Table  1.  Overview  of  LVCAR-I  Efforts. 


Within  the  LVC  Future-Oriented  Efforts  technical  area, 
efforts  were  further  subdivided  into: 

a.  Service-Oriented  Architecture  (SOA)  Application  to 
LVC  Simulations;  and 

b.  LVC  Futures. 

From  a  functional  perspective,  however,  these  technical 
areas  can  be  reformulated  into  several  major  objectives: 

1 .  Prototyping  LVC  Simulation  Standards; 

2.  Advancing  the  Reuse  of  LVC  Simulation  Assets; 

3.  Increasing  the  Commonality  of  Data  Storage 
Formats; 

4.  Improving  the  Use  of  Gateways  and  Bridges  for 
LVC  Simulations; 

5.  Investigating  LVC  Architecture  Convergence;  and 

6.  Investigating  the  Application  of  Additional 

Technologies  to  LVC  Simulations. 

The  following  sections  discuss  each  of  the  above 
objectives,  and  the  progress  made  to  date  in  achieving 
them  in  the  first  two  years  of  LVCAR  implementation. 
In  most  cases,  these  individual  efforts  have  been 
documented  in  technical  papers  that  have  been  previously 
presented  at  the  semi-annual  Simulation  Interoperability 
Workshops  (SIWs)  and  the  annual  Interservice/Industry 


Training,  Simulation  &  Education  Conference  (I/ITSEC), 
as  well  as  other  venues.  For  example,  a  full-day 
workshop  on  the  initial  progress  of  the  effort  was 
conducted  at  the  2010  Spring  SIW  [2]  to  get  feedback 
from  the  broader  M&S  community.  The  purpose  of  this 
paper  is  not  to  repeat  prior  papers  in  detail,  but  rather  to 
present  a  consolidated  summary  of  the  first  two  years  of 
the  project  that  can  be  used  as  a  reference  point  for 
further  exploration  of  the  more  detailed  efforts.  Citations 
of  publicly  available  technical  papers  on  the  more 
detailed  efforts  are  made,  where  appropriate.  Project- 
specific  technical  reports  on  the  various  efforts  are 
available  through  appropriate  program  channels. 

3.  Prototyping  LVC  Simulation  Standards 

Although  simulation  standards,  to  gain  widespread 
acceptance  within  the  community,  need  to  be  developed 
using  a  consensus-based  process,  it  is  sometimes 
necessary  to  “seed”  the  development  of  such  standards  by 
undertaking  a  funded  effort  to  create  a  prototype  upon 
which  subsequent  volunteer  efforts  can  be  based.  In  the 
area  of  LVC  simulations,  it  was  felt,  based  on  the 
LVCAR  study,  that  there  were  two  areas  in  which  such 
prototype  efforts  were  needed: 

•  A  Multi-Architecture  Systems  Engineering  Process 
for  LVC  Simulations;  and 

•  An  LVC  Federation  Agreements  Template. 

3.1  Multi- Architecture  Systems  Engineering  Process 

Robust,  well-defined  systems  engineering  (SE)  processes 
are  a  key  element  of  any  successful  development  project. 
In  the  distributed  simulation  community,  there  are  several 
such  processes  in  wide  use  today,  each  aligned  with  a 
specific  simulation  architecture  such  as  Distributed 
Interactive  Simulation  (DIS),  the  High  Level  Architecture 
(HLA),  and  the  Test  and  Training  Enabling  Architecture 
(TENA).  However,  there  are  an  increasing  number  of 
distributed  simulation  applications  within  the  Department 
of  Defense  (DoD)  that  require  the  selection  of 
simulations  whose  external  interfaces  are  aligned  with 
more  than  one  simulation  architecture.  This  is  what  is 
known  as  a  multi-architecture  simulation  environment. 

Many  technical  issues  arise  when  multi-architecture 
simulation  environments  are  being  developed  and 
executed.  These  issues  tend  to  increase  program  costs 
and  can  increase  technical  risk  and  impact  schedules  if 
not  resolved  adequately.  One  of  the  barriers  to 
interoperability  identified  in  the  LVCAR  Final  Report  [1] 
was  driven  by  a  community-wide  recognition  that  when 
user  communities,  aligned  with  the  different  simulation 
architectures,  are  brought  together  to  develop  a  multi¬ 
architecture  distributed  simulation  environment,  the 


differences  in  the  development  processes  native  to  each 
user  community  adversely  affected  the  ability  to 
collaborate  effectively.  Rather  than  developing  an 
entirely  new  process,  it  was  recognized  that  an  existing 
process  standard  should  be  leveraged  and  extended  to 
address  multi-architecture  concerns.  The  process 
framework  that  was  chosen  was  the  Institute  of  Electrical 
and  Electronics  Engineers  (IEEE)  standard  called  the 
Distributed  Simulation  Engineering  and  Execution 
Process  (DSEEP). 

The  LVCAR-I  team  augmented  the  major  DSEEP  steps 
and  activities  with  the  additional  tasks  that  are  needed  to 
address  the  issues  that  are  unique  to  (or  at  least 
exacerbated  by)  multi-architecture  development.  These 
tasks  collectively  define  a  “how  to”  guide  for  developing 
and  executing  multi-architecture  simulation 
environments,  based  on  recognized  best  practices.  Over 
40  multi-architecture-related  issues  were  identified,  based 
on  an  extensive  literature  search.  Each  of  these  issues 
was  aligned  with  the  activity  in  the  DSEEP  for  which  the 
issue  first  becomes  relevant.  This  information  was 
provided  as  an  overlay  to  corresponding  information 
already  provided  in  the  DSEEP  document  for  single¬ 
architecture  development.  A  pictorial  of  the  multi¬ 
architecture  issues  aligned  with  the  DSEEP  is  shown  in 
Figure  1. 

The  initial  prototype  of  the  DSEEP  Multi-Architecture 
Overlay  (DMAO)  was  produced  by  the  team  in  the 
summer  of  2010,  and  revised  in  the  winter  of  2010-11. 
The  Simulation  Interoperability  Standards  Organization 
(SISO)  has  formed  a  Product  Development  Group  (PDG), 
in  which  members  of  the  LVCAR-I  team  are 
participating,  to  take  the  initial  prototype  DMAO  and 
evolve  it  into  a  consensus-based  IEEE  standard. 

3.2  Federation  Agreements  Template  and  Tool 

Federation  agreements  are  critical  to  the  successful 
design,  execution,  and  reuse  of  federation  assets. 
However,  inconsistent  formats  and  use  across  federations 
have  made  it  difficult  to  capture  and  compare  agreements 
between  federations.  This  lack  of  a  consistent  approach 
to  documenting  federation  agreements  makes  reuse  and 
understanding  more  difficult.  Lack  of  consistent  format 
also  prevents  tool  development  and  automation.  The 
LVCAR-I  team  developed  a  prototype  Federation 
Engineering  Agreements  Template  (FEAT)  to  provide  a 
standardized  format  for  recording  federation  agreements 
to  increase  their  usability  and  reuse. 

The  template  is  an  extensible  Markup  Language  (XML) 
schema  from  which  compliant  XML-based  federation 
agreement  documents  can  be  created.  XML  was  chosen 
for  encoding  agreements  documents  because  it  is  both 
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human-  and  machine-readable  and  has  wide  tool  support. 
Creating  the  template  as  an  XML  schema  allows  XML- 
enabled  tools  to  both  validate  conformant  documents,  and 
edit  and  exchange  agreements  documents  without 
introducing  incompatibilities.  Wherever  possible,  the 
LVCAR-I  team  leveraged  existing,  authoritative  schemas 
for  the  representation  of  elements  in  this  schema, 
including: 

•  Modeling  and  Simulation  (M&S)  Community  of 
Interest — Discovery  Metadata  Specification  (MSC- 
DMS) 

•  XML  Linking  Language  (XLink) 

•  XML  Metadata  Interchange  (XMI) 

•  Common  Platform  Enumeration  (CPE) 

•  Intelligence  Community  Information  Security 
Marking  (IC-ISM) 

•  extensible  Configuration  Checklist  Description 
Format  (XCCDF) 

•  Geography  Markup  Language  (GML) 

The  federation  agreements  are  decomposed  into  eight 
categories: 

1.  Metadata — Information  about  the  federation 
agreements  document  itself. 

2.  Design — Agreements  about  the  basic  purpose  and 
design  of  the  federation. 

3.  Execution — Technical  and  process  agreements 
affecting  execution  of  the  federation. 

4.  Management — Systems/software  engineering  and 
project  management  agreements. 

5.  Data — Agreements  about  structure,  values,  and 
semantics  of  data  to  be  exchanged  during  federation 
execution. 

6.  Infrastructure — Technical  agreements  about 
hardware,  software,  network  protocols,  and 
processes  for  implementing  the  infrastructure  to 
support  federation  execution. 


Modeling — Agreements  to  be  implemented  in  the 
member  applications  that  semantically  affect  the 
current  execution  of  the  federation. 

8.  Variances — Exceptions  to  the  federation  agreements 
deemed  necessary  during  integration  and  testing. 

The  prototype  FEAT  schema  was  produced  by  the 
LVCAR-I  team  during  2010.  SISO  has  formed  a  PDG,  in 
which  members  of  the  LVCAR-I  team  are  participating, 
to  take  the  initial  prototype  FEAT  and  evolve  it  into  a 
consensus-based  SISO  standard. 

Because  of  the  complexity  of  the  schema,  the  LVCAR-I 
team  recognized  that  most  users  would  need  a  tool  to  be 
able  to  implement  it  effectively.  In  the  winter  of  2010- 
11,  the  LVCAR-I  team  developed  an  initial  prototype 
FEAT  editor  tool  that  implements  some  key  elements  of 
the  schema.  The  tool,  which  has  received  an  “EAR  99” 
export  designation  so  that  it  can  be  exported  to  all  but  a 
few  countries,  was  provided  in  its  initial  prototype  form 
to  the  SISO  PDG  so  others  could  experiment  with  it  and 
improve  it.  The  intent,  once  required  approvals  are 
obtained,  is  to  make  the  FEAT  tool  an  open-source 
software  product. 

Both  the  prototype  DMAO  and  the  prototype  FEAT  and 
its  editor  tool  were  developed  as  part  of  the  LVC 
Common  Capabilities  technical  area  of  the  project.  A 
paper  on  all  of  the  Common  Capability  efforts  was 
presented  at  the  2010  I/ITSEC  [3]. 

4.  Advancing  the  Reuse  of  LVC  Simulation 

Assets 

It  is  generally  accepted  that  LVC  simulation  assets,  like 
assets  in  the  broader  M&S  community,  have  not  achieved 
the  desired  degree  of  reuse  across  DoD.  Many  reasons 
for  that  have  been  postulated.  In  attempting  to  advance 


Figure  1.  Multi- Architecture  Issues  Overlaid  on  the  DSEEP. 

7. 


the  reuse  of  LVC  simulation  assets,  the  LVCAR-I  team 
explored  two  areas: 

•  Alternative  Business  Models  for  Reuse 

•  Asset  Reuse  Mechanisms 

4.1  Investigation  of  Alternative  Business  Models  for 
Reusing  LVC  Simulation  Assets 

The  LVCAR  Final  Report  [1],  in  its  Comparative 
Analysis  of  the  Architectures  and  Comparative  Analysis 
of  Business  Models,  identified  two  significant 
impediments  to  sharing  and  reuse  of  event  development 
tools  across  programs  and  communities.  The  first  is  the 
existence  of  a  wide  range  of  tools  utilizing  a 
correspondingly  wide  range  of  business  models.  The 
second  impediment  is  the  current  environment  where 
different  formats  are  used  by  the  different  architectures  to 
store  like  event  data.  The  LVCAR-I  team  first  undertook 
a  study  effort  to  identify  the  most  beneficial  approaches 
to  facilitate  tool  sharing  across  architectures  based  on  a 
structured  analysis  of  the  current  state. 

As  a  result  of  the  study  effort,  the  LVCAR-I  team 
identified  a  desired  migration  path  based  on  the  current 
states  of  LVC  tools,  which  is  shown  in  Figure  2. 


Figure  2.  Migration  Paths  for  LVC  Tools. 


Individual  long-term  recommendations  based  on  the 

analysis  represented  in  Figure  2  were  as  follows: 

1.  For  legacy  DoD-owned  tools,  consider  a  shift  to 
open  source,  to  reduce  DoD  costs  and  foster  potential 
innovations.  Use  the  experiences  from  an  open- 
source  pilot  to  decide  if  this  should  be  done,  and  if 
so,  what  considerations  exist  for  LVC  tools. 

2.  For  new  tools,  where  there  is  a  desire  to  provide 
DoD  influence  but  to  defray  ownership  costs,  use  an 
open-source  model  also  informed  by  the  open-source 
pilot. 

3.  Where  small  numbers  of  licenses  are  purchased  from 
industry,  do  not  make  a  change. 

4.  Where  a  large  number  of  licenses  have  been  and 
continue  to  be  procured  from  industry,  take  the 
following  actions  in  the  order  presented  until  a  viable 
option  is  identified: 


a.  Shift  to  open  source.  This  assumes  that  vendors 
are  willing  and  the  open-source  pilot  experience 
indicates  there  is  benefit  to  DoD. 

b.  Shift  to  software-as-a-service.  This  assumes 
that  vendors  are  willing  and  the  experiences 
from  a  software-as-a-service  pilot  show  benefit 
to  DoD  exists. 

c.  Attempt  to  negotiate  DoD-wide  discounted 
licenses. 

5.  For  current  open-source  efforts,  make  no  changes. 

6.  If  preferred-provider  lists  have  been  established, 
attempt  to  establish  DoD-wide  discounted  licenses, 
using  the  experiences  gained  from  a  central-licensing 
pilot. 

7.  For  existing  centrally-negotiated  licenses,  do  not 
make  a  shift. 

8.  The  study  team  was  unaware  of  any  existing 
software-as-a-service  arrangement  for  LVC  tools,  so 
no  recommendations  in  terms  of  a  shift  from  current 
practices  are  made. 

9.  For  all  business  models,  increase  the  visibility  of 
what  tools  are  currently  used,  and  take  steps  to 
increase  the  visibility  of  user  experiences  as 
indicated  by  the  LVC  Asset  Reuse  Mechanism 
effort. 

10.  Consistent  with  DoD  policy,  use  open  standards  as  a 
basis  for  tool  procurements,  and  participate  in 
standards  development  activities  to  ensure  DoD’s 
needs  are  met. 

Based  on  these  recommendations,  which  were  published 
in  the  summer  of  2010,  the  LVCAR-I  team  embarked 
upon  attempts  to  conduct  pilot  efforts  for  software-as-a- 
service,  central  licensing,  and  open-source  software. 

In  the  software-as-a-service  area,  a  Request  for 
Information  (RFI)  was  drafted,  and  was  issued  via  a  new 
mechanism  provided  by  the  Program  Executive  Office, 
Simulation,  Training,  and  Instrumentation  (PEO-STRI). 
A  relatively  small  number  of  responses  were  received, 
which  are  currently  being  evaluated  for  lessons  learned 
for  potential  future  such  activities.  A  specific  tool  to  use 
for  the  central-licensing  pilot  has  not  yet  been  identified, 
but  discussions  are  underway  in  one  area.  Finally,  for  the 
open-source  pilot,  it  is  likely  that  the  FEAT  tool 
discussed  above  will  be  the  primary  open-source 
candidate,  although  sources  of  existing  tools  that  use 
traditional  business  models  that  might  be  willing  to 
migrate  to  an  open-source  business  model  are  still  being 
investigated. 

4.2  LVC  Simulation  Asset  Reuse  Mechanisms 

As  mentioned  earlier,  the  reuse  of  software,  data,  and 
other  assets  in  DoD  M&S  development  is  seen  as  being 
neither  as  frequent  nor  as  effective  as  it  could  be,  and  as  a 


consequence,  the  potential  benefits  of  reuse  to  the  DoD 
enterprise  are  not  being  fully  realized.  Improvements  in 
the  enterprise  culture  and  processes  supporting  reuse  are 
needed  to  increase  the  frequency  of  reuse.  Three 
alternative  approaches  to  accomplishing  those 
improvements  were  defined  and  evaluated  by  the 
LVCAR-I  team.  An  assessment  of  multiple  existing 
repositories  using  a  carefully  developed  set  of  M&S- 
oriented  evaluation  criteria  was  conducted  to  identify 
where  enhancements  are  needed. 

The  LVCAR-I  team  examined  13  existing  M&S  catalogs, 
repositories,  and  registries  of  interest  to  the  LVCAR-I 
effort  and  evaluated  the  applicability  of  these  and  other 
reuse  initiatives.  A  detailed  model  of  LVC  asset  reuse 
mechanisms  based  on  22  comprehensive  reuse  use  cases 
tied  to  the  DoD  Net-Centric  Data  Strategy  and 
commercial  standards  for  repositories  was  developed  and 
used  to  facilitate  the  research  and  analysis  conducted. 
Consideration  of  the  state  of  these  LVC  asset  reuse 
mechanisms,  together  with  feedback  from  stakeholders 
within  all  communities  enabled  by  M&S  in  the  form  of 
questionnaires,  workshop  discussions,  and  interaction  in 
the  government-industry  profession,  informed  this  study 
and  recommendations. 

Three  complementary  approaches  to  improve  LVC  Asset 
Reuse  Mechanisms  were  examined.  The  Transactional 
Approach  focuses  on  enhancing  the  discovery  and 
acquisition  of  reusable  M&S  assets  through  a  set  of 
distributed,  interconnected  M&S  catalogs,  registries,  and 
repositories.  The  Social  Marketing  Approach  addresses 
the  long-term  improvement  of  behaviors  that  promote 
reuse  of  M&S  assets.  The  Process-Based  Approach 
encourages  more  frequent  reuse  by  enhancing  reuse 
guidance  within  standard  DoD  M&S  systems  engineering 
process  models.  These  three  approaches  were  evaluated 
in  terms  of  desirability,  achievability,  and  affordability, 
as  well  as  the  likely  barriers  to  their  success. 

The  Transactional  Approach  was  rated  as  the  most 
affordable  due  to  existing  investments  and  is  roughly 
equivalent  to  the  Process-Based  Approach  in  terms  of 
desirability.  The  Process-Based  Approach  was  rated  as 
the  most  easily  achievable  based  on  its  compatibility  with 
ongoing  standards  initiatives  in  M&S  systems 
engineering  processes,  and  also  an  emerging  impetus 
towards  SOAs.  A  Social  Marketing  Approach  was  rated 
as  the  least  mature  in  all  three  indices  of  desirability, 
achievability,  and  affordability,  but  it  offers  some  unique 
methods  to  increase  reuse  frequency.  Barriers  to  the 
success  of  the  Social  Marketing  and  Process-Based 
Approaches  were  rated  as  equal  in  difficulty. 

Building  upon  the  results  of  the  initial  evaluation,  which 
was  completed  in  the  summer  of  2010,  the  LVCAR-I 


team  embarked  upon  an  effort  to  build  a  prototype 
product  that  would  enable  better  asset  reuse.  The 
Enterprise  Metacard  Builder  Resource  (EMBR)  Portal 
prototype  was  completed  in  early  2011,  and  is 
instantiated  on  a  web-accessible  server  maintained  by 
SimVentions,  Inc.  It  provides  the  ability  to  create 
metacards,  based  on  the  MSC-DMS,  for  LVC  assets, 
allows  links  to  locations  where  those  assets  may  be 
obtained,  and  provides  a  mechanism  for  users  to 
comment  on  their  use  of  the  assets,  and  interact  with 
other  users.  Further  information  on  the  EMBR  Portal 
may  be  found  in  Ref.  [4]. 

5.  Increasing  the  Commonality  of  Data 
Storage  Formats 

The  LVCAR  Final  Report  [1]  recommended  actions  to 
promote  the  sharing  of  tools,  data,  and  information  across 
the  DoD  enterprise  and  to  foster  common  formats  and 
policy  goals  to  promote  interoperability  and  the  use  of 
common  M&S  capabilities.  One  of  the  recommended 
actions  was  to  examine  different  data  storage  formats 
used  across  the  various  architectures  to  determine  the 
feasibility  of  creating  a  set  of  architecture-independent 
formats.  Such  formats  would  be  used  for  storage  of 
classes  of  data  in  order  to  mitigate  the  cost  and  schedule 
impacts  of  database  conversion,  minimize  conversion 
errors,  and  improve  consistency  across  LVC 
architectures.  The  focus  of  the  LVCAR-I  effort  in  this 
area  is  limited  to  data  interchange  formats  and  applicable 
standards  where  the  data  is  persistent,  e.g.,  in  stored 
datasets. 

The  LVCAR-I  team  identified  nine  categories  of  data 
storage  formats,  based  on  expertise  and  feedback 
received  at  the  LVC  Common  Capabilities  Workshop  at 
JHU/APL  in  November  2009  and  questionnaires 
administered  in  person  at  the  2009  I/ITSEC  conference 
and  online.  This  stakeholder  feedback  was  used  to  assess 
the  priority  for  rationalization  of  data  storage  formats  for 
each  category.  The  team  examined  the  contents  of  eight 
metadata  standards  registries,  catalogs  and  repositories 
for  each  category  identified.  These  sources  included  the 
DoD  Metadata  Registry,  the  DoD  Information 
Technology  Standards  and  Profile  Registry  (DISR),  the 
North  Atlantic  Treaty  Organization  (NATO)  and  DoD 
M&S  Standards  Profile,  and  the  Acquisition  Streamlining 
and  Standardization  Information  System  (ASSIST) 
database,  in  addition  to  privately  maintained  source 
materials. 

For  each  of  the  nine  format  categories,  a  list  of  applicable 
formats  was  compiled  and  characterized  in  terms  of 
currency,  openness,  maturity,  and  applicability  as  a 
source  (producer),  interchange  (mediation)  and 


executable  (consumer)  data  format.  This  information  was 
used  to  assess  the  difficulty  of  rationalizing  formats 
within  each  category. 

In  addition,  the  team  developed  a  strategy  for  each  of  the 
nine  categories  by  evaluating  the  feasibility  of  moving  to 
a  state  of  greater  reuse  via  a  combination  of: 

1.  Reduction  in  the  number  of  formats  used  in  each 
category; 

2.  Standardization  of  formats  in  each  category  if  no 
standards  exist; 

3.  Increased  adoption  of  mediation  formats  to  reduce 
translation  errors;  and 

4.  Creation  or  engagement  with  category-specific 
communities  of  interest  (COIs). 

Using  this  prioritization  approach,  the  team  concluded 
that  the  standardized  formats  should  be  pursued  in  the 
following  order: 

Priority  1 :  Manmade  features  and  event  results 
Priority  2:  Geospatial 

Priority  3:  Unit  Order  of  Battle  (UOB)  and  Plans  / 
scenarios 

Priority  4:  Platform/weapons  performance  and  behavior 
Priority  5:  Electronic  Order  of  Battle  (EOB)/network  and 
logistics. 

The  initial  assessment  effort  was  completed  in  the  early 
summer  of  2010.  Based  on  an  assessment  of  where  these 
priorities  were  already  being  investigated  or  planned  to 
be  investigated  within  the  broader  DoD  community,  as 
well  as  the  expected  cost  of  developing  reasonable 
solutions,  the  team  narrowed  its  focus  to  making  specific 
recommendations  in  five  of  the  original  nine  categories 
starting  in  the  summer/fall  of  20 10: 

1.  Three-dimensional  (3D)  manmade  features 

2.  Platform/weapon  performance/characteristics 

3 .  Event  results 

4.  Logistics 

5.  UOB  /  force  structure 

Of  the  above,  there  appeared  to  be  little  Service-based 
interest  in  standardization  of  platform/weapon 
performance/characteristics.  In  the  logistics  area, 
extensions  to  the  Joint  Land  Component  Constructive 
Training  Capability  (JLCCTC)  Entity  Resolution 
Federation  (ERF)  logistics  data  model  and 
representations  were  recommended. 

In  the  3D  manmade  features  category,  the  LVCAR-I 
team  has  developed  recommendations  for  specific 
extensions  to  X3D.  In  the  event  results  category, 
although  mature  after-action  review  systems  exist,  the 
data  formats  they  use  are  both  non-standardized  and 
custom-tailored  to  the  data  model  of  the  simulation  they 


are  logging.  So  the  LVCAR-I  team  has  developed  a  draft 
XML  schema  for  event  results.  In  the  UOB  /  force 
structure  category,  the  team  continues  to  monitor  the 
progress  in  standardized  data  formats  being  performed  by 
Military  Scenario  Definition  Language  (MSDL)  and 
Coalition  Battle  Management  Language  (C-BML)  efforts. 
Technical  papers  on  the  team’s  work  in  each  of  these 
areas  are  being  prepared  for  presentation  at  the  2011  Fall 
SIW. 

6.  Improving  the  Use  of  Gateways  and 
Bridges  for  LVC  Simulations 

The  LVCAR  Final  Report  [1]  presented  a  vision  for 
achieving  significant  interoperability  improvements  in 
LVC  simulation  environments.  The  study  recommended 
several  activities  intended  to  reduce  the  time  and  cost 
required  to  integrate  mixed-architecture  events.  Three  of 
the  key  LVCAR  report  recommendations  were  to 
determine  whether  existing  gateway  and  bridge 
applications  were  effective  in  meeting  user  requirements, 
whether  improvements  in  gateway/bridge  capabilities 
were  necessary  to  address  identified  gaps,  and  how  these 
improvements  could  be  best  implemented  to  maximize 
DoD  return  on  investment  (ROI).  The  term  “bridge”  in 
this  context  refers  to  intelligent  translators  that  link 
together  enclaves  of  simulations  that  use  the  same 
underlying  simulation  architecture.  A  “gateway”  is  also 
an  intelligent  translator  but  is  designed  to  link  simulation 
enclaves  that  use  dissimilar  architectures. 

Early  during  the  LVCAR-I  effort,  the  team  performed 
gateway  and  bridge  literature  research,  compiled  the 
team’s  gateway  and  bridge  usage  and  development 
experience,  and  developed  formal  gateway  and  bridge 
operation  terminology.  At  this  point,  it  became  clear  that 
the  distinction  between  “gateway”  and  “bridge”  was 
moot  from  a  development  and  usage  standpoint.  Starting 
with  the  initial  delineation  of  capabilities,  the  team 
compiled  a  Gateway  Capabilities  Matrix  Template,  and 
created  two  structured  questionnaires  (one  for  gateway 
developers,  and  one  for  gateway  users).  A  one-day 
workshop,  the  “LVCAR  Common  Gateways  and  Bridges 
Workshop,”  was  held  in  March  2010  to  present  the 
findings  of  the  questionnaires.  There  was  wide 
agreement  that  there  are  several  potential  improvements 
that  can  be  made  that  will  lower  the  technical  and  cost 
risks  generally  associated  with  the  use  of  gateways. 

Based  on  the  above,  in  the  early  summer  of  2010,  the 
team  developed  three  potential  strategies  for  execution, 
referred  to  as  Educate,  Enhance,  and  Create  (as  well  as  a 
“Status  Quo”  strategy),  as  shown  in  Figure  3.  Of  the  four 
strategies,  the  team  recommended  that  the  Enhance 
strategy  be  executed,  because  it  was  perceived  to  have  the 


greatest  ROI.  More  information  on  the  LVCAR-I  team’s 
first  year  of  efforts  on  gateways  may  be  found  in  Ref.  [5]. 
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Figure  3.  Potential  Strategies  for  Improving 
Gateways. 


■  Development  of  a  repository  for  GDL-based  gateway 
descriptions,  incorporating  applicable  search  and 
requirements-to-capabilities  matching  algorithms. 

■  Development  of  tools  for  GDL  and  SML  file 
creation  and  editing. 

■  Development  of  SML  Translators  for  selected 
gateways 

■  JBUS  and  Gateway  Builder  (GWB)  are  likely 
choices 

■  Socialization  of  the  preliminary  set  of  GPBs  with 
gateway  developer  organizations,  incorporation  of 
feedback,  and  preparation  of  a  formal  specification. 

■  Development  of  a  gateways  tutorial. 

Early  work  in  the  second  year  of  effort  on  gateways  is 

documented  in  Refs.  [6]  through  [8], 


The  LVCAR-I  team  then  embarked  on  the  execution  of 
the  Enhance  strategy,  also  incorporating  the  tutorial 
recommendation  given  as  part  of  the  Educate  strategy. 
During  the  past  year,  the  LVCAR-I  team  has  developed 
the  following  products: 

■  A  Gateway  Configuration  Model  that  identifies  an 
explicit  set  of  gateway  requirements,  and  discusses 
how  the  emerging  gateway  products  and  processes 
will  address  those  requirements. 

■  A  Gateways  Capability  Description  document, 
which  formally  delineates  the  various  capabilities 
that  individual  gateways  can  offer  to  user  programs, 
along  with  specific  levels  of  implementation  for  each 
unique  capability. 

■  An  assessment  of  the  Architecture-Neutral  Data 
Exchange  Model  (ANDEM),  originally  developed  by 
the  Joint  Composable  Object  Model  (JCOM)  effort, 
to  support  Simulation  Data  Exchange  Model 
(SDEM)  mapping  and/or  translation  in  gateways. 

■  A  preliminary  set  of  Gateway  Performance 
Benchmarks  (GPBs)  to  identify  specific  gateway 
performance  measures,  along  with  use  cases  that 
describe  how  and  where  these  measures  should  be 
applied. 


7.  LVC  Architecture  Convergence  -  Perhaps 
a  Bridge  Too  Far 

The  LVCAR  Final  Report  [1]  developed  a  vision  for 
achieving  significant  interoperability  improvements  in 
LVC  simulation  environments.  The  study  recommended 
activities  proposed  to  lower  the  time  and  cost  required  to 
integrate  mixed  architecture  events  by  building  better 
bridges  between  the  legacy  architectures  (discussed  in  the 
previous  section)  and  making  the  architectures  more 
compatible.  As  part  of  the  LVCAR-I  effort,  the  team 
explored  converging  the  current  architectures. 

Rather  than,  for  example,  making  the  current  HLA  like 
the  current  TENA,  the  team’s  goal  was  to  make  future 
HLAs  more  like  future  TENAs.  Subject  matter  experts 
(SMEs)  from  each  architecture  (HLA,  TENA,  DIS,  and 
the  Common  Training  Instrumentation  Architecture 
(CTIA),  participated  together  on  the  LVCAR-CT.  Each 
SME  provided  existing  documentation  resources  and 
identified  where  in  the  documents  to  extract  the  key 
services  and  tools.  Using  this  information,  the  team  first 
developed  a  document  that  characterized  the  existing 
architectures. 


The  following  efforts  are  in  progress: 

■  Development  of  a  common  Gateway  Description 
Language  (GDL),  in  a  machine-readable 
format/syntax,  for  describing  both  user  gateway 
requirements  and  the  capabilities  that  individual 
gateways  can  offer,  to  support  user  discovery  of 
needed  gateway  capabilities. 

■  Development  of  a  common  SDEM  Mapping 
Language  (SML)  to  formalize  format  and  syntax  of 
mappings  between  different  SDEMs,  to  reduce  the 
number  of  required  mappings,  and  to  support  reuse 
of  mapping  data. 


The  next  step  was  to  determine  what  actions  would  lead 
to  convergence.  The  vision  was  that  in  2015,  new 
versions  of  CTIA,  DIS,  HLA,  and  TENA  would  emerge 
that  would  incorporate  the  results  of  the  convergence 
effort.  The  LVCAR-I  team  described  the  envisioned 
converged  architecture  in  terms  of  how  it  would  execute 
in  a  multi-architecture  event.  This  converged  execution 
would  contain 

1.  Simulations  that  need  not  be  aware  that  multiple 
architectures  are  in  use, 

2.  Parts  of  the  support  infrastructure  of  the  legacy 
infrastructures,  and 

3.  A  common  shared  library  for  communication. 


This  concept  was  selected  because  it  requires  no  changes 
to  the  simulations  (which  are  the  area  of  greatest  DoD 
M&S  investment).  As  a  result,  changes  under  this 
proposed  solution  would  impact  only  a  few  infrastructure 
providers  and  require  significantly  less  investment  to 
achieve  convergence.  Construction  of  software  to 
gradually  evolve  legacy  infrastructures  and  achieve 
convergence  would  involve  several  years  of  effort. 

As  part  of  its  first-year  efforts,  the  LVCAR-I  team  also 
calculated  an  estimate  of  the  investment  that  would  be 
required  over  a  number  of  years  to  achieve  the  envisioned 
converged  state,  as  well  as  the  return  that  was  expected  to 
be  realized  over  many  years.  Those  estimates  are  shown 
in  Figure  4.  Upon  review  of  the  timelines  and  costs,  the 
government  decided,  because  of  the  magnitude  of  the 
investment,  and  the  number  of  years  required  to  achieve  a 
“break-even”  state,  to  terminate  any  continuing  effort  on 
architecture  convergence  activities  during  the  summer  of 
2010.  More  details  on  the  year-long  convergence  effort 
may  be  found  in  Ref.  [9]. 
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Figure  4.  ROI  Estimates  for  Architecture 
Convergence. 


8.  Investigating  the  Application  of  Additional 
Technologies  to  LVC  Simulations 

In  addition  to  the  primary  areas  of  investigation  discussed 
above,  the  LVCAR-I  team  was  asked  to  look  toward  the 
future  at  different  technologies  that  might  improve  LVC 
simulations.  The  first,  SOAs,  have  been  in  use  in  other 
communities,  so  the  question  is  the  degree  to  which  SOA 
might  apply  to  LVC  simulations.  To  address  this,  a  study 
of  benefits  and  barriers  of  SOA  application  to  LVC  was 
undertaken  by  JHU/APL  members  of  the  LVCAR-I  team, 
and  a  pilot  application  of  SOA  to  LVC  was  undertaken 
by  MITRE.  Looking  even  farther  ahead,  members  of  the 
JHU/APL  LVCAR-I  team  undertook  a  small  “LVC 
Futures”  study  to  see  how  future  technologies  might  be 
applied  to  LVC  simulations  in  the  2025  timeframe. 


8.1  Service-Oriented  Architectures  -  Benefits  and 
Barriers 

The  goal  of  the  DoD  to  reuse  M&S  assets,  such  as 
visualization  software,  data  management  applications, 
and  interoperability  middleware,  is  similar  to  the  goal  of 
the  business  community  to  reuse  existing  business 
applications  in  the  architectural  paradigm  of  SOA.  This 
common  association  with  reusability  suggests  that  the 
integration  of  SOA  and  distributed  simulation  would  be  a 
good  combination,  but  not  all  M&S  applications  lend 
themselves  to  SOA-based  solutions. 

Although  SOA  infrastructures  can  and  have  been  applied 
to  mid-size  LVC  distributed  simulations  in  a  few  efforts, 
the  question  remains,  is  SOA  a  good  fit?  To  answer  this 
question,  an  examination  of  the  benefits  of  and  barriers  to 
the  application  of  SOA  to  LVC  distributed  simulations  is 
required.  The  LVCAR-I  team  enumerated  eight  benefits 
of,  and  seven  barriers  to,  applying  SOA  to  LVC 
distributed  simulations. 

In  short,  SOA  was  assessed  to  be  an  excellent 
architectural  choice  for  an  LVC  distributed  simulation  if 
the  criteria  below  are  met. 

■  If  there  exist  multiple  contributors  to  a  LVC 
distributed  simulation  that  have  clearly  defined  areas 
of  interest,  each  have  a  willingness  to  take 
ownership,  and  all  have  a  stake  in  the  overall  success 
of  the  resulting  simulation  system. 

■  If  there  is  a  critical  need  for  the  ability  to 
dynamically  add  components,  allow  updates  to  keep 
components  current,  or  reconfigure  a  system  in 
relatively  short  order. 

■  If  the  simulation  components  are  well-encapsulated 
through  the  use  of  an  agreed  upon  common  SDEM 
for  the  LVC  distributed  simulation. 

■  If  all  simulation  components  will  be  operating  at 
similar  levels  of  abstraction  for  the  objects  and 
interactions  within  the  simulation. 

■  If  all  simulation  components  will  be  operating  at  the 
same  echelon  of  security. 

■  If  the  modeling,  visualization,  and  management 
control  can  be  segmented  within  the  infrastructure. 

■  If  translation  components,  i.e.,  gateways,  can  be 
incorporated  into  the  federations,  or  are  definable  as 
services  themselves,  then  scalability  of  the  system  is 
increased. 

■  If  a  business  model  can  be  defined  and  maintained 
where  it  is  beneficial  to  share  the  cost  of  LVC 
distributed  simulations. 

On  the  other  hand,  SOA  was  assessed  to  be  a  poor 
architectural  choice  for  an  LVC  distributed  simulation  if 
any  of  the  following  conditions  exist. 


•  If  all  parties  cannot  agree  on  goals,  interfaces,  and  an 
evolution  plan,  and  the  ability  to  record  these 
agreements  in  governance  documents. 

•  If  the  funding  and  time  are  not  available  to  permit 
components  to  be  written  so  that  they  are  usable  in  a 
more  general  way,  are  available  as  a  service,  and 
external  requests  for  updates  are  heeded. 

•  If  the  LVC  distributed  system  being  developed  does 
not  need  to  be  updated  frequently  to  meet  its  goals, 
such  as  static  training,  testing,  experimentation,  or 
demonstration  that  is  unchanging;  then,  SOA  is  too 
heavyweight  an  infrastructure. 

•  If  throughput  is  a  significant  concern,  as  SOA 
infrastructures  are  traditionally  written  as  remote 
services  employing  request-response-based 
communication  protocols,  such  as  web  services. 

•  Being  able  to  create  services  out  of  simulation 
components  is  difficult,  since  simulation  components 
are  not  traditionally  a  request-response  entity. 
However,  the  SOA  infrastructure  most  likely  should 
not  be  applied  at  the  level  of  the  simulation 
component,  but  rather  at  the  level  of  the  simulation 
cluster.  The  exception  to  this  is  that  the  SOA 
infrastructure  can  be  used  exclusively  to  initialize, 
configure,  and  deploy  simulation  components,  and 
allow  the  distributed  simulation  infrastructures,  i.e., 
HLA,  TENA,  and  DIS,  to  process  the  simulation-to- 
simulation-component  communication. 

•  Current  simulation  infrastructures  are  often 
composed  in  brittle  ways.  If  components  are 
reconfigured  and  redeployed  on-the-fly,  the 
distributed  simulation  is  not  likely  to  not  operate 
properly.  Most  components  would  have  to  be 
updated  to  handle  the  challenges  of  rapid 
deployment. 

•  The  use  of  a  SOA  infrastructure  in  the  DoD  M&S 
community  is  only  cost  effective  if  the  system  gains 
a  wide-enough  acceptance  for  the  services  to  be 
used. 

In  summary,  SOA  does  appear  to  have  a  greater  upfront 
cost  and  may  provide  a  greater  cost  savings  over  the 
long-term  through  reuse  and  a  potentially  cost-effective 
business  model,  such  as  software-as-a-service.  SOA 
requires  greater  cooperation  among  distributed  simulation 
developers  than  traditional  development.  In  addition,  the 
challenges  associated  with  SOA  are  both  political  and 
social,  as  well  as  technical.  Whether  the  successes 
achieved  on  a  few  mid-size  distributed  simulation  tasks 
can  be  scaled  up  to  full-size  simulation  exercises  still 
remains  to  be  seen. 

In  addition  to  documenting  the  benefits  and  barriers  of 
SOA  application  to  LVC  simulations  in  a  technical 
report,  the  LVCAR-I  team  has  produced  a  tutorial  on  this 


topic.  Evolving  versions  of  the  tutorial  were  presented  at 
the  2010  Fall  SIW,  the  2010  post-I/ITSEC  tutorial 
session,  and  the  2011  Spring  SIW.  A  DVD  of  the  tutorial 
has  also  been  produced  and  distributed  to  the  LVCAR-I 
DoD  sponsoring  organizations,  to  enable  the  tutorial’s 
use  in  a  non-classroom  setting. 

8.2  Service-Oriented  Architecture  Pilot  Effort 

The  concept  of  using  SOA-based  software  technologies  is 
not  new  and  is  being  eyed  with  keen  interest  by  many  in 
the  simulation  industry.  However,  no  extant  program  of 
record  can  afford  to  put  their  program  at  risk  on  an 
unproven  approach,  no  matter  how  promising.  The  2008 
DoD  study,  LVCAR  Final  Report  [1],  recommends  to 
“Take  actions  that  can  reduce  or  eliminate  the  barriers  to 
interoperability  across  the  architectures.”  As  an  early 
step  toward  addressing  the  LVCAR  recommendation,  a 
“SOA  Outlook"  pilot  effort  was  developed  to  determine 
if  commercial  SOA  architectures,  software,  and 
principles  are  an  appropriate  solution  space  for  achieving 
LVC  interoperability. 

The  pilot  was  designed  around  the  use  of  open  standards 
wherever  possible  and  attempts  to  illustrate  SOA 
principles  like  composition  and  reuse.  A  common  data 
abstraction  layer  in  the  application  server  provided  an 
abstraction  of  the  storage  mechanism  through  the  Java 
Persistence  Application  Programming  Interface  (JPA) 
standard  and  allowed  for  non-system-specific  storage  of 
shared  data.  Integration  with  existing  legacy  systems 
used  a  two-part  adaptor  /  plug-in  architecture  where  the 
adaptor  connects  directly  to  the  existing  infrastructure 
and  communicates  with  its  plug-in  counterpart  inside  the 
application  server  infrastructure.  (See  Figure  5.)  The 
pilot  also  included  a  sample  of  other  services  that  would 
be  required  for  a  complete  interoperability  framework. 

The  SOA  pilot  successfully  provided  a  limited 
interoperability  framework  based  on  the  constraints  of  the 
use  case  selected  and  the  level  of  effort  involved. 
Cursory  performance  data  was  also  gathered  and 
reported. 

8.3  Potential  Future  Technology  Application  to  LVC 
Simulation 

The  “LVC  Futures”  study  effort  set  out  in  2010  to 
investigate  emerging  technologies  and  processes  in  the 
2025  timeframe  and  their  impact  on  M&S  activities  in 
support  of  future  DoD  activities.  By  first  proposing  a  set 
of  possible  future  operational  vignettes  (e.g.,  military, 
disaster  relief),  the  LVCAR-I  team  applied  near-term 
technologies  that  could  have  substantial  impact  in  an 
M&S  context  for  the  DoD  and  other  coalition  partners 
within  the  context  of  these  vignettes.  Additionally,  the 


LVC  Futures  task  looked  towards  processes  that  woidd 
impact  future  socialization  of  and  collaboration  within 
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Figure  5.  LVC  SOA  Pilot  Architecture. 


To  frame  the  technology  investigation,  the  team 
generated  five  vignettes  to  capture  the  scope  of  future 
operational  needs.  Each  of  these  vignettes  included 
consideration  of: 

•  Operations  -  conventional,  cyber,  joint, 
stability/aid,  irregular,  counter-insurgency 

•  Services  -  Army,  Navy,  Air  Force,  Marine 
Corps 

•  Reserves  /  National  Guard 

•  Time  Horizon  -  weeks,  months,  years 

•  Foreign  military  participation 

•  Non-governmental  organizations  /  Corporations 


Using  the  vignettes,  the  team  estimated  a  technology’s 
impact  for  M&S  activities,  including  skill  training,  unit 
training,  mission  planning,  environmental  analysis,  C4I 
structure,  and  acquisition.  These  impacts  were 
summarized  in  tables  for  each  technology  to  create  an 
effects  matrix  with  seven  possible  gradations  of  impact. 


Technologies  and  processes  were  binned  into  nine 
categories  in  the  broader  areas  of  implementation,  and 
socialization  and  adaptation,  as  follows. 


Implementation 

•  Mobile  computing  and  augmented  reality 

•  Ubiquitous  surveillance  and  automated 
reasoning 

•  Event-model  driven  architectures 


•  Self-healing  /  self-managing  systems 

•  M&S  social  graph 
Socialization  and  adaptation 

•  Crowd-sourcing 

•  Mash-up  software  and  FIST  (Fast,  Inexpensive, 
Simple,  Tiny) 

•  Cloud  encapsulation 

•  Everything  is  a  game 

Results  of  the  team’s  efforts  during  2010  are  given  in 
Ref.  [10].  In  the  summer  of  2011,  an  implementation 
plan  is  being  prepared  for  a  potential  prototype  for  rapid 
situational  awareness  that  builds  on  the  “everything  is  a 
game”  category  above. 

9.  The  Way  Ahead 

The  LVCAR-I  task  was  approved  for  continuation 
through  fiscal  years  2011  and  2012  by  the  DoD  M&S 
Steering  Committee.  The  LVCAR-I  team  is  currently 
building  upon  the  accomplishments  in  the  first  two  years 
described  in  this  paper  to  advance  LVC  processes  and 
products. 

In  the  standards  area,  working  through  SISO  in 
conjunction  with  the  larger  M&S  community,  the  DMAO 
is  expected  to  become  an  IEEE  standard,  and  the  FEAT  a 
SISO  standard,  by  the  end  of  the  LVCAR-I  project. 
Similarly,  the  tool  to  aid  users  in  implementing  the  FEAT 
is  expected  to  become  a  complete  product,  under  an 
open-source  licensing  arrangement. 

Lessons  learned  in  the  exploration  of  alternative  business 
models  for  DoD  LVC  tools,  including  the  use  of  open 
source  software,  software-as-a-service,  and  central 
licensing,  will  be  documented  so  that  future  LVC  tool 
developments  can  take  better  advantage  of  these  business 
models.  Common  data  storage  format  advances  in 
several  areas  will  have  been  made  by  the  end  of  the 
LVCAR-I  project  in  the  areas  of  3D  formats  and  battle 
management  languages,  which  will  provide  a  strong 
baseline  for  future  efforts  in  this  area  by  other  projects, 
such  as  the  Rapid  Data  Generation  (RDG)  effort. 

Gateway  users  will  have  automated  tools  at  their  disposal 
to  aid  in  discovering  appropriate  gateways  for  specific 
uses.  Additionally,  some  common  components  for 
SDEM  translation  will  have  been  developed  to  aid  in  the 
application  of  gateways.  Building  on  the  EMBR  portal, 
an  LVC  asset  reuse  repository  will  be  available  to  support 
LVC  gateway  discovery  and  reuse,  which  can  serve  as  a 
model  for  expanded  repository  efforts  for  the  broader 
M&S  community. 
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